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♦ Use of Design Models in SLS 

• Design models and requirements: reducing cost 

• Use of M&S to reduce conservatism and enhance launch 
vehicle knowledge 

♦ Early risk reduction obtained through use of M&S 




Space Launch System 


Orion 

Interim Cryogenic 
Propulsion Stage 


Block I 

70 metric tons 


Five-Segment 
Solid Rocket Boosters 

First Flight 
planned for 2018 
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Core Stage 



S3 4 RS-25 Engines 


5, 8.4 or 10 Meter 
Payload Fairings 


Upper Stage 


Block II 
130 metric tons 


Liquid or Solid 
Advanced Boosters 


SLS Status 



Engine tests with new controller 
Increased inlet pressures 




Use of Design Models in SLS 
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Requirements Goal with Use of M&S 


♦ Goal - Define a process to employ on SLS to minimize 
requirements and attendant verification using engineering models. 

♦ Why? 

• Reduce the verification effort necessary for the Elements to satisfy vehicle- 
level requirements specifying the details of the system design 

• Reduce the verification effort necessary at the integrated vehicle level to track 
and roll up verification of all the detailed requirements 

•Allow the Elements the flexibility to adjust the detailed subsystem values to 
Element benefit without requesting approval for each detailed change 
-Don’t specify each detail, only control the output of the system model 

• Use of a single model for a system guarantees that the system-level impacts 
of changes will be visible, whereas specifying the detailed individual values 
does not. The model is needed anyway; the requirements are not. 

•Avoids the experience of having a system design that works, models that 
accurately show its behavior, but having to negotiate what the detailed 
requirements should be and how to verify them. 

-e.g. Booster TVC model works, but in standard approach we would negotiate detailed 
TVC requirements. 

• Reduces resulting conservatism 



Key Points used in determining which 
Parameters to Elevate to a Requirement 


♦ If the System is Sensitive to the Model Parameter Limits and the 
Limits are a design driver, ELEVATE 

♦ Not elevating a Model Parameter saves resources 

• Determining the ‘hard’ limits for parameters can be an intensive analytical 
effort 

• Debates on adequate margin included in a requirement can be prolonged 

• Each additional requirement adds documentation and tracking 

♦ The program accepts the additional Risk when a requirement is not 
elevated 

• Cost/Schedule Risk if we have to set a new requirement to get a model 
parameter “back in the box” 

• Or technical risk of accepting the model parameter as is 



Examples of which model parameters are 
elevated to requirements 


Mass Properties 


Thrust Vector Control 


Inertial Navigation System 


Elevated to Requirements 

Dry Mass, Prop Load Limits 
-Rationale: directly affects SLS 
requirements, clear limits 
known 

Core Stage Gimbal range and 
rate 

Rationale: Limits are significant 
driver in Core Stage design 
and limits are needed for 
design to proceed 

Vehicle Ascent Insertion 
Accuracy 

Rationale: INS design and the 
navigation accuracy are highly 
sensitive to this and limits are 
needed for design to proceed. 


Model Output Parameters 

Time dependent Cg 
Rationale: Vehicle can 
accommodate multiple 
solutions, just needs to know 
the correct values 

Booster Gimbal range and 
rate: 

Rationale: Parameters are 
based on heritage and little risk 
that model outputs will become 
unacceptable. 

Vehicle Position 
Rationale: Producing this 
output is part of the functional 
design definition of the INS 
and an auditable parameter 


Inertial Navigation System Example 


Traditional Requirements 
for INS System could result 
in 230 Shall Statements 

♦ Requirements for anti- 
aliasing portion: 

• The inertial measurements 
shall be anti-aliased 

• Anti-alias filter shall have a 
bandwidth of 29.5 Hz 

• Anti-alias filter shall execute 
at a minimum sample 
frequency of 250 Hz 

• Anti-alias filter shall have a 
maximum phase lag of 5 
degrees at 1 Hz. 

• Anti-alias filter shall have a 
maximum gain of +/- 2e-3 dB 
at 1 Hz 

• Anti-alias filter shall have a 
minimum attenuation of 6 dB 
at 20 Hz 


+ Anti-Aliasing Filter Implementation Model in Code 


Model Input Data: 


TF method 
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enableTFdyn w 

1 

omega w hz 

29.5 

zeta w 

0.6 

TF T w hz 

250.0 

enableTFdyn a 

1 

omega a hz 

26.5 

zeta a 

0.6 

TF T a hz 

250.0 


# 2nd order TF method: 

# 1) continuous with Euler integration, 

# 2) continuous using MAVERIC integration, 

# 3) discrete with Tustin transform 

# enable 2nd order transfer function 

# Gyro bandwidth frequency (Hs) 

# second order damping factor 

# Sampling freq for discrete filter (Hz) 

# enable 2nd order transfer function 

# Accel bandwidth frequency (Hz) 

# second order damping factor 

# sampling frequency for discrete filter (Hz) 


♦ Implementation in Code - little ambiguity in intent or 
assumptions 

♦ Alternate implementations are available. If coefficients are 
specified, they would be dependent upon a fixed execution 
rate, and therefore could be constrained. 

♦ Alternate designs are possible. As long as the vehicle-level 
needs are satisfied, these can be explored without detailed 
requirements revision. 

♦ Customer works directly with the subsystem folks to agree 
on the model that meets the integrated vehicle needs and 
works best for the Element 



Some Advantages of Using Models 


♦ Vehicle level doesn’t need to see the verification of 
each detail, just that the model matches the hardware 
and meets the top-level vehicle needs 

♦ If the contractor wanted to propose a completely new 
system, e.g. GPS/INS, it would be reflected by a 
completely different model. Using the approach of 
many detailed requirements, the contractor is led to a 
specific INS solution or has to change many 
requirements in order to change the system. With the 
model-based approach, if the new model meets the 
vehicle needs, changing to the new system is much 
easier. 



Models May Not Work Best in All Cases 


♦ For example, slosh damping requirements 

• Model is a complicated characterization of slosh behavior 

• Requirement characterization is simple, and exceeding the required value is all 
that is needed (see figure) 

• A model is still necessary 

Predicted LOX 



FLUID LEVEL FROM BOTTOM OF TANK, INCHES 



Types of Models Used for SLS at the Vehicle Level 


4 Element system models (propulsion, finite element, mass 
properties, TVC, navigation, ...) 

4 Avionics box models 

4 Vehicle models (aerodynamics-16, finite element, mass properties, 
MPS, ...) 

4 Integrated simulations (MAVERIC, CLVTOPS, ML _Pogo, ARTEMIS, 

...) 

4 Requirements definition (aerothermal, venting, loads, debris, ...) 

4 Guidance, Navigation, and Control (GN&C) model 
4 Mission and Fault Manager 
4 Probabilistic Risk Assessment 
4 Discrete Event Simulation for operations planning 



Design Model Verification 


Acceptable model for Refined model at DCR 

high uncertainty 



♦ If acceptance data is outside the performance of DCR models, the models 
will be updated and flight performance will be reassessed as part of 
system acceptance 


+ Element model delivery: 

•Models are developed in accordance with SLS-PLAN-173, SLSP Modeling and Simulation Plan 

• Design models used at the System Level are maintained in the SLS-RPT-105, SLSP Design 
Model Log 

• Design models are delivered in accordance with SLS-STD-038, SLSP Design Model Delivery 

Standard 



The Design Model Delivery Standard 


♦ SLS-STD-038 uses a streamlined subset of the Credibility Assessment Factors 
defined in the NASA Modeling and Simulation Standard (NASA-STD-7009) 

♦ Model verification and validation are established and uncertainties reported to the 
level necessary for each development milestone before a model is baselined 

♦ Reassessed with each model delivery or update 


SLS-STD-038 

BASELINE 

RELEASE DATE: JANUARY 12. 2012 


SPACE LAUNCH SYSTEM PROGRAM (SLSP) DESIGN 
MODEL DELIVERY STANDARD 



National Aeronautics and 
Space Administration 


Approved for Public Release; Distribution is Unlimited. 

The electronic version is the official approved document. 

Verify this is the correct version before use. 



Design Models Meta Data 


♦ The meta data controlled with the design models 

• Bookkeeping (Identifier, Version, Release Date, Model Name, SLS 
Element/Subsystem, Dependencies on other models, Milestone applicability) 

• Statement of Intended Use 

• Technical Description of Model spells out the required system inputs, outputs, 
test cases 

• Assumptions 

• Operational Phase (applicability) 

• Verification 

• Validation 

• Results Uncertainty (identifies and quantifies uncertainty of model output) 

• Results Robustness 

• Limitations (provides boundaries on the set of parameters for which a model result 
is valid) 

• Input Pedigree (includes the uncertainty of input data) 

• Use History 

• Conservatism 

- So that an evaluation can be performed when the design is sensitive to the model, and so 
that conservatism doesn’t get piled on top of conservatism. 



How Has Use of M&S Helped SLS Early? 

A Few Examples 


Advanced Concepts 


4 INTROS is a MSFC-developed tool that does conceptual launch 
vehicle design and sizing based on stage geometry and mass 
properties. 

• Mass properties are established for selections from a large master list of launch 
vehicle systems, subsystems, propellants and fluids. 

• Mass calculations are based on mass estimating relationships (MERs) that are 
automatically generated from a large database of MERs that is built into the 
program. 

• Program mass calculation accuracy for existing and historical launch vehicles 
has been verified to be well within 5%. 

4 LVA is a MSFC-developed tool that provides fast launch vehicle 
structural design and analysis. 

• It supplies detailed analysis by using time proven engineering methods based 
on material properties, load factors, aerodynamic loads, stress, elastic stability, 
deflection, etc. 

•This tool and its predecessors have been in use at MSFC for over 25 years. 

4 POST is an industry-standard trajectory optimization tool. 

4 Once a candidate configuration is developed in INTROS, these tools 
are used iteratively to converge on viable design solutions. 



How Has Use of M&S Helped SLS Early? 


♦ Prior to SRR/SDR, analyzed items such as these using models 

• Engine out capability 

• RGA number and location 
•Vehicle sizing trade 

• Attitude control (P/Y/R) need for CS/US rate at Payload Separation 
•T-0 stay need, do we need it, where, active damping? 

•Core Stage Engine throttling needs (max dynamic pressure, inlet 
pressure, separation bolts, max accel) 

• Determined the necessary number of engines for all evolved versions 
•Trajectory runs with CFD-generated line loads 

• Used models for loads generation and aerothermal conditions 
•6DOF dispersed analysis for insertion accuracy, performance, impact 

footprint, attitude rates for separation events, trajectories for loads & 
induced environments, separation clearance analyses 

• Early estimates of Flight Performance Reserve needed without extra 
conservatism 

• Modeling of heavy/slow and light/fast vehicles 



Flex Mode Dispersions vs Finite 
Element Model Dispersions 


♦ Traditional techniques for 
dispersing flex modes 

• Independent dispersions 

- No correlation between shape and 
frequency 

• Non-physical responses 
requires minimal set of modes 
to be used (~10) 

• Limits spectrum for analysis 


♦ Dispersed FEM 

• Randomly disperse FEM based 
on input uncertainties 

• Shape and frequency 
correlated 

• Responses are all physically 
realizable 

• Significant increase in analyzed 
spectrum (-200 modes) 



Altitude 


Day of Launch Wind Biasing 


♦ PDR Time Frame 

* Day of launch wind biasing to reduce buffet loads by reducing maximum 
total angle of attack 


Pitch Plane Example Yaw Plane Example 



Wind Speed 



Day of Launch Wind Biasing Process 



1 ) Obtain latest wind profiles, 
splice and filter. 

2) Design open loop 
commanded attitude 
profile. 




AlphaTotal Knockdown (deg) 


Day of Launch Wind Biasing Process 


♦ Examples of Day of Launch Process Results 

• Enhanced knowledge of correct knockdowns to use 

• Enhanced knowledge of launch availability 

•Ability to trade parameters, for example wind filtering frequency and wind 
measurement timeline 




Led to Answers/Design Solutions Early? 


♦ PDR Time Frame 

• Designed a good Design Reference Mission 
for ICPS contractor. 

-Result of 6DOF Monte Carlo dispersion studies 

• Forward attach bolt adjust and throttle down to 
relieve excess bolt loads 

• No tower flyaway maneuver and wind placard to 
relieve acoustic loads 

• Identified inlet pressure concern for stuck throttle 
cases 

• Resolved controllability concern related to 
vehicle aft structure flexibility and aft RGA 

• ICPS tank stretch from simulation work 

• Navigation state vector update 

♦ CDR Time Frame 

• Aerothermal exceedances for certain 
engine out cases due to increased angle of 
attack 

- Might not have found these previously, or 
might have needed a lot more work to find 
them. Simple MC runs overnight, with 
computer compilation of the results. Found 
just before CDR. Using simulation to mitigate. 



-50 0 50 100 

South - North Drift (ft) 



Improved Analysis of Failure Cases 


♦ Failure and abort cases, Monte Carlo nominal and failure runs done 
early. 

♦ More sophisticated abort triggers improves crew safety. 

♦ Saturn V had a fixed value for a bad case. 



Max 

w/ Gusts 

Trig Adj 2 

— Trig Adj 1 
Orig Trig 


Abort Trigger Setting 



Improved Analysis of Failure Cases 


♦ Excess time (after detecting the failure and departing) available for 
escape 

♦ Color indicates the first vehicle limit that was exceeded 

♦ Could point to an issue that needs to be worked further 




Monte Carlo Stability Analysis 



♦ PDR Time Frame 

• Monte Carlo analysis of stability margins, allows for reduced conservatism. 
•This is a gain in many design areas: instead of piling worst on worst, or bad on 
bad, Monte Carlo results are statistical. 


phase 



Some Other Uses of Models in SLS 


♦ Using discrete event simulation to model the operations process, 
assembly, test, etc. To optimize the flow, understand the long poles 
in the tent, and understand how long each operation will take. 

♦ Modeling of solid rocket booster options using stick traces and 
rules from Booster Element, to optimize Booster along with resizing 
of a stage or other trade parameters. 


Stick traces with 
constraints defined 
by Booster 
personnel, used by 
trajectory/sizing 
personnel 




Conclusion 


♦ Modeling and Simulation has enabled SLS to 
•Reduce cost 
•Find issues sooner 
•Provide higher fidelity results 
•Allow more design flexibility 
•Reduce excess conservatism 

•Provide for increased mission success and crew safety 
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